Electronic devices are used in a variety of products, from personal computers to automobiles to toys. There are various different types of electronic devices, such as, for example, an integrated circuit. Furthermore, as those of skill in the art will appreciate, electronic devices can be connected, to form other electronic devices or systems. The designing and fabricating of electronic devices typically involves many steps, sometimes referred to as the “design flow.” The particular steps of a design flow often are dependent upon the type of electronic device, its complexity, the design team, and the fabricator that will manufacture the device.
Several steps are common to most design flows. Initially, the specification for a new design is expressed, often in an abstract form and then transformed into lower and lower abstraction levels until the design is ultimately ready for manufacture. The process of transforming the design from one level of abstraction to another is referred to as synthesis. At several stages of the design flow, for example, after each synthesis process, the design is verified. Verification aids in the discovery of errors in the design, and allows the designers and engineers to correct or otherwise improve the design. The various synthesis and verification processes are facilitated by electronic design automation (EDA) tools.
As those of ordinary skill in the art will appreciate, the synthesis and verification processes applied to modern designs are quite complex and include many different steps. An illustrative design flow, for an integrated circuit, for example, can start with a specification for the integrated circuit being expressed in a high-level programming language, such as, for example, C++. This level of abstraction is often referred to as the algorithmic level. At this abstraction level, the functionality of the design is described in terms of the functional behavior applied to specified inputs to generate outputs. The design will then be synthesized into a lower level of abstraction, typically, the logic level of abstraction. At this level of abstraction, the design is expressed in a hardware description language (HDL) such as Verilog, where the circuit is described in terms of both the exchange of signals between hardware registers and the logical operations that are performed on those signals. As this stage, verification is often performed to confirm the functional behavior of the design, i.e. that the logical design conforms to the algorithmic specification.
After the logical design is verified, it is synthesized into a device design. The device design, which is typically in the form of a schematic or netlist, describes the specific electronic devices (such as transistors, resistors, and capacitors) that will be used in the circuit, along with their interconnections. This device design generally corresponds to the level of representation displayed in conventional circuit diagrams. Verification is again performed at this stage in order to confirm that the device design conforms to the logical design, and as a result, the algorithmic specification.
Once the components and their interconnections are established, as represented by the device design, the design is again synthesized, this time into a physical design that describes specific geometric elements. The geometric elements define the shapes that will be created in various layers of material to manufacture the circuit. This type of design often is referred to as a “layout” design. The layout design is then used as a template to manufacture the integrated circuit. Verification is typically performed again at this stage, to ensure that the layout design conforms to the device design.
As those of ordinary skill in the art will appreciate, modern design flows are often an iterative process. More specifically, the design flow steps of synthesizing the design, verifying the synthesized design, and then modifying the design based on the results of verification are often repeated a number of times. This iterative process can become even further complicated as design goals and objectives change during development. Any such changes will further necessitate additional modifications to the design. In turn, additional synthesis and verification process must be repeated.
Although there are different methods of performing verification, this invention is directed towards verification processes that “exercise” a design by applying input to the design and capturing the output resulting from application of the input. The applied input is often referred to as an input sequence. The captured output then is compared to the output the design should have produced according to the input sequence and the specification. Various technologies exist for exercising a design, for example, the response (i.e. the output) of the design to the input sequence, may be simulated. In some cases the output may be captured from an emulator, emulating the design with the input sequence as stimulus for the emulation. A prototype may also be used to generate the output. Those of ordinary skill in the art will appreciate that combinations of simulation, emulation, and prototyping could be used during verification and that various combinations of technologies can be employed to implement a verification system as described here. Typically, the tools used to exercise a design as described above are referred to as the “test bench.”
Verification typically consists of applying multiple input sequences, referred to as a test set and capturing each resulting output, referred to as an output set. The outputs from the output set then are compared to the corresponding expected outputs. There are many ways to generate test sets. For example, directed tests, that is, where the input sequences are directly specified by a designer can be used. Random combinations of inputs can also be selected and used to form input sequences. Although ideally one would generate an input sequence that corresponds to all possible input combinations, the set of all possible input sequences to a modern electronic design is so large that it is not computationally feasible to exhaustively test the design in this manner. As a result, another approach to generating input sequences for verification, referred to as coverage-based verification is often used.
With a coverage-based verification process, constraints on the set of all possible inputs are specified, and then input sequences that satisfy these constraints are generated. More specifically, the potential inputs that may be selected to form an input sequence from are restricted by using constraints. Then input sequences are generated from, the remaining (i.e. unrestricted) inputs. Typically, inputs, input values, and combinations of inputs or input values that are required to exercise portions of the design's functionality are identified. Constraints then are written based on these identified inputs and input values. The set of constraints is often referred to as a coverage model. Verification progress then is measured by achieving the coverage described by the coverage model. More specifically, an acceptable level of verification is selected where input sequences corresponding to some portion of the coverage model are generated and included in the test set during verification. As the coverage model is often based on key features and functions of the design, it is often desirable that input sequences which exercise the entire coverage model be generated. Tools, referred to herein as “test set generators” are available that provide for the generation of test sets as detailed above.
The test set generator is typically connected to the test bench. As such, during iterations of the design flow, the test set can be updated or adjusted based on any modifications made to the design. Connecting a test bench to a test set generator involves matching design elements referenced in the test bench to corresponding design elements with which the test set generator can use to generate test sequences. This is referred to herein as a map between the test bench and the test set generator. Although most conventional test set generator tools are able to produce a reasonably complete map for a number of different hardware description languages, those of ordinary skill in the art will appreciate that the user must often modify the map somewhat at the start of the design process. During subsequent iterations of the design process then, these modifications may be eliminated as the map is updated to account for modifications to the design. As such, the user supplied sections of the map must be maintained during iterations of the design flow, in order to prevent the user from having to again modify the map.